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METHOD AND SYSTEM FOR SECURE AUTHENTICATED 
PAYMENT ON A COMPUTER NETWORK 

FIELD OF THE INVENTION 

The present invention relates to a method and system for secure authenticated 
payment at a point-of-sale on a computer network. More particularly, the present inven- 
tion allows the use of digital signatures on a sales draft to authenticate purchasers in a 
manner that does not necessarily require any changes in the transaction processing of the 
financial institutions participating in the transaction. 

BACKGROUND OF THE INVENTION 

In present electronic commerce transactions, buyers may pay for goods and 
services by presenting the seller with a payment card number, e.g., a conventional credit 
card number. Because the buyer and seller are connected solely through a computer 
network (e.g., the Internet), it is not possible for the buyer to authenticate himself as the 
legitimate cardholder, nor can the buyer sign the sales draft. Thus, the seller honors any 
valid credit card number that is presented, creating a large opportunity for fraud. 

Worse yet, other forms of payment such as debit cards are not presently viable on 
computer networks. Debit cards require the cardholder to enter a personal identification 
number ("PIN"), which is used to authenticate the transaction to the cardholder's bank. 
However, entering a simple PIN on a networked computer poses a substantial security 
risk — if the PIN and the debit-card number fell into the wrong hands, the cardholder's 
bank account would be completely compromised. 

Thus, with respect to both conventional credit and debit cards, authenticating a 
cardholder on the network with a solution that is simple, secure, and easy to deploy 
remains an important unsolved problem. 

Digital signature technology offers one means of authenticating the cardholder 
with a high degree of security. In this technology, each cardholder owns a pair of keys - a 
signature (private) key and a verification (public) key. The cardholder signs a transaction 
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with his private key, and then sends the transaction, the digital signature, and (optionally) 
his public key to the merchant. The merchant forwards these items to the bank (or other 
financial institution), and the bank honors the transaction if the cardholder's public key 
verifies the cardholder's digital signature. 
5 One security advantage of digital signatures is that the private key of the card- 

holder typically remains in possession (or at least control) of the cardholder. Thus, there is 
no inherent risk associated with a transaction that would compromise future transactions. 
One disadvantage of the digital signature method described above is that banks and 
transaction processors would have to change their existing infrastructure to allow digital 

10 signatures to flow through their networks. This infrastructure change would basically 

require a substantial overhaul of the present electronic banking and transaction processing 
system, which is costly and difficult to achieve. 

Thus, there is a need for a method and system that offers the security advantages of 
digital signatures without necessarily requiring significant changes in the banking and 

1 5 processing network. 

SUMMARY OF THE INVENTION 

One embodiment of the present invention includes a simple, secure and easy-to- 
deploy method and system for authenticating credit and/or debit cardholders at a point-of- 
sale on a computer network (e.g., the Internet). Cardholders are authenticated using digital 

20 signatures on a sales draft, in a manner that does not necessarily require any changes in the 
transaction process of the financial institutions participating in the transaction. 

In this embodiment of the system, the cardholder enrolls for an electronic payment 
card (either an electronic debit or credit card) at a participating financial institution by 
visiting its issuer proxy enrollment site, e.g., a web site hosted by an issuer proxy com- 

25 puter associated with the financial institution. At the enrollment site, the cardholder types 

in his particulars, such as his conventional payment card number, conventional payment 
card PIN, name, address, etc. The cardholder also (optionally) selects a password (access 
code) for his electronic payment card that is preferably unrelated to the PIN for his 
conventional payment card. The issuer proxy generates a public key-private key pair for 
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use by the cardholder if the car iholder does not already have such a pair. The issuer proxy 
binds the cardholder's public key and some or all of the cardholder's payment particulars in 
a digital certificate using an encryption key (called a domain key) that is shared between 
the issuer proxy and a bridge computer. Such a domain key will allow the bridge computer 
to confirm the issuer's certification during a subsequent authorization stage, described 
below. The cardholder then receives a piece of software that is downloaded to his 
computer containing his particulars in encrypted form. This piece of software constitutes 
the cardholder's electronic payment card. It comprises (or is configured to obtain and use) 
the cardholder's private key, which is (optionally) protected by the password, and the 
corresponding public-key digital certificate containing the cardholder's payment particu- 
lars. 

Thenceforth, as the cardholder shops online, he can elect to pay via electronic 
payment. To do so, the cardholder activates his electronic payment card with the previ- 
ously selected password. The cardholder's electronic payment card software interacts with 
corresponding software at the online merchant to digitally sign the sales draft created 
during the transaction with the cardholder's private key. The merchant then sends the 
signed sales draft and the cardholder's digital certificate to the bridge computer for 
processing. The bridge computer uses the cardholder's digital certificate to check the 
digital signature on the sales draft. If the signature is valid, the bridge computer creates a 
conventional debit or credit transaction to be processed by the banking and transaction 
network. The particulars needed for creating the conventional transaction, such as the 
conventional card number and PIN, are extracted and decrypted from the cardholder's 
digital certificate using the private key associated with the domain key (if the digital 
certificate was asymmetrically encrypted) or the domain key itself (if the digital certificate 
was symmetrically encrypted). The embodiment of the invention described above 
provides one or more or the following advantages: 

(1 ) Additional hardware at the cardholder's computer is not necessarily required for 
deployment. This is in marked contrast to hardware tokens such as smart cards, 
where cards and card readers are required. Of course, the software comprising the 
cardholder's electronic payment card can be stored on smart cards, as well as 
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virtually any other storage medium, including, without limitation, floppy disks, 
hard drives, and magnetic stripe cards; 

(2) Changes are not necessarily required in the existing banking network; 

(3) Administrative overhead is low. The cardholder can enroll at any participating 
financial institution that offers the service, not necessarily the one that issued the 
cardholder's conventional payment card. Furthermore, enrollment can be on a self- 
serve basis and does not necessarily require activation mailings by the financial 
institutions; 

(4) Electronic payment cards can be deployed rapidly, because they are intuitive to use 
and require little user or administrator training; and/or 

(5) Security can be enhanced via special techniques such as "cryptographic camouflag- 
ing," which is commercially available from Arcot Systems, Inc. 

The foregoing and other embodiments and aspects of the present invention will 
become apparent to those skilled in the art in view of the subsequent detailed description 
of the invention taken together with the accompanying figures and appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram illustrating an exemplary computer system for secure 
authenticated payment on a computer network. 

FIG. 2 is a flow chart illustrating an exemplary method for cardholder enrollment 
for an electronic payment card. 

FIG. 2A illustrates an exemplary electronic payment card created using the 
preferred embodiment of the invention. 

FIG. 3 is a flow chart illustrating an exemplary method for point-of-sale interaction 
between a cardholder and a merchant. 

FIG. 4 is a flow chart illustrating an exemplary method for a merchant to obtain 
authorization for the payment transaction. 
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DETAILED DESCRIPTION OF THE INVENTION 

FIG. 1 is a block diagram illustrating an exemplary computer system for secure 
authenticated payment on a computer network (e.g., the Internet). The system contem- 
plates a network of computers including a cardholder's computer 100, a payment card 
issuer's proxy computer 110, a merchant's computer 120, a bridge computer 130, a 
payment gateway computer 140, and legacy backend computer 150. In this exemplary 
embodiment, the network is deployed over the Internet, although those skilled in the art 
will recognize that any public or private communication network including, without 
limitation, extranets, intranets, and other telephonic or radio communications networks 
could also be used. Similarly, as used herein, the term computer refers to any device that 
processes information using an integrated circuit chip, including without limitation 
mainframe computers, work stations, servers, desktop computers, portable computers, 
embedded computers, and hand-held computers. 

Enrollment 

Referring now to FIG. 2, at step 200, a cardholder (user) at computer 100 enrolls 
for an electronic payment card (either an electronic debit card or an electronic credit card) 
at the electronic payment card issuer proxy 1 1 0, typically by visiting the website of a 
participating financial institution on the Internet. At step 210, the cardholder provides the 
issuer 1 10 with particular information used to make a payment (payment particulars), such 
as his conventional payment card number, conventional payment card PIN, conventional 
credit card holder verification value 2 ("CVV2"), conventional cardholder name and 
address, or any other cardholder identification information. The issuer proxy 1 1 0 can be 
operated by any trusted financial institution that participates in the electronic payment 
system, not necessarily the financial institution that issued the cardholder's conventional 
payment card. 

The issuer proxy 110 can optionally verify the cardholder's payment information 
by any of the means available for such verification including, without limitation, creating a 
payment transaction in the conventional payment network. Such a transaction could be 
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"authorization only" in the sense that it would be used only for verifying the cardholder's 
payment particulars, with no money actually transferred. 

At step 220, the issuer 110 generates a public key-private key pair for the card- 
holder to use in connection with the electronic payment system. If the cardholder already 
5 has a public key-private key pair that he wishes to use in connection with the electronic 

payment system, he provides his public key to the issuer 110. The cardholder's private key 
is typically stored on the cardholder's computer 100, often under the control of a PIN or 
other form of access code (password). The access code can be protected against unautho- 
rized detection using commercially available software technology such as software smart 
10 cards from Arcot Systems, Inc., described in "Software Smart Cards via Cryptographic 

Camouflage," Proceedings IEEE Symposium on Security and Privacy, May 1999, and in 
co-pending US patent application number 08/996,758, "Method and Apparatus for Secure 
Cryptographic Key Storage Certification and Use," which is incorporated herein by 
reference. 

1 5 The access code may also be protected against unauthorized detection (e.g., so- 

called "shoulder surfing") using the technology described in co-pending US patent 
application number 09/249,043, "Method and Apparatus for Secure Entry of Access Codes 
in a Computer Environment," which is incorporated herein by reference. 
At step 230, the issuer 110 binds the cardholder's public key and some or all of the 

20 cardholder's payment particulars in a digital certificate, typically by encrypting the 

cardholder's public key and particular identifying information provided by the cardholder. 
The encryption key used for encrypting the cardholder's payment particulars - called the 
domain key - is typically shared between the issuer proxy 1 1 0 and the bridge computer 
130, and may be either a symmetric key or an asymmetric encryption key. In one 

25 embodiment, the domain key may be a public key associated with the bridge computer 

130, so that only the bridge computer 130 can decrypt the encrypted cardholder particulars 
(using a corresponding private key associated with the bridge computer 130). In another 
embodiment, the domain key may be a symmetric encryption key that is shared by the 
issuer proxy 1 10 and the bridge computer 130. In either case, the bridge computer will use 

30 the domain key (actually, its private key counterpart, if asymmetric; or the domain key 

itself, if symmetric) to verify the binding, as will be described later in the section entitled 
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"Authorization." After the issue r proxy 1 1 0 combines the cardholder's public key with 
some or all of the cardholder's payment information and digitally signs the combination to 
create a digital certificate for the cardholder, the digital certificate for the cardholder is 
loaded into an electronic payment card for the cardholder. Of course, those skilled in the 
art will realize that many other types of binding can be used including, without limitation, 
offloading the signing to a trusted third party, or receiving (rather than creating) the digital 
certificate from the user (although such binding is less secure). 

At step 240, the issuer 1 10 sends and the cardholder's computer 100 receives the 
cardholder's electronic payment card, e.g., a piece of software that is downloaded to the 
cardholder's computer 100. The electronic payment card (typically stored in a software 
wallet) may be further protected against unauthorized access via a PIN (preferably 
different from the PIN associated with the cardholder's conventional payment card) or 
other form of user access code. The access code may be protected against unauthorized 
detection by the above-mentioned procedures used to protect the private key PIN. (Indeed, 
if the two PINs are the same, private key access for digitally signing and electronic 
payment card access for transaction execution could be accessed via a single protocol.) 
Setting the access code (PIN) for the electronic payment card is preferably done when the 
electronic payment card is being created by the issuer 110, but can also be done separately, 
e.g., when the cardholder first accesses his electronic payment card on the cardholder 
computer 100. 

Alternatively, if the cardholder wishes to be able to perform electronic transactions 
from a variety of locations, the cardholder's private key and/or electronic payment card 
may be stored at a credential server and downloaded on the fly by a roaming cardholder 
using a shared secret or challenge-response protocol. In the latter case, commercially 
available software such as Arcot WebFort from Arcot Systems, Inc., described at 
http://www.arcot.com/products.html and in co-pending U.S. patent application number 
09/196,430, "Method and Apparatus for Secure Distribution of Authentication Credentials 
to Roaming Users," which is hereby incorporated by reference, may be used to effect the 
roaming functionality. 

One advantage of this enrollment process is that the issuer's participation can be 
passive, in that the issuer proxy 110 can be operated by any trusted financial institution 
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that participates in the electronic payment system, and is not necessarily the bank or 
financial institution that issued the conventional payment card to the cardholder. This is 
important because it suffices that one well-recognized financial institution participates in 
the system. Furthermore, even the participation of this financial institution can be limited 
to establishing the issuer proxy 1 10 on the network for self-service access by the card- 
holder, and does not require mailings to the cardholder, or other physical interaction with 
the cardholder. 

FIG. 2A illustrates an exemplary electronic payment card created using the 
preferred embodiment of the invention, in which the card contains: (a) the cardholder's 
digital certificate, comprising the cardholder's payment particulars, and his public key, 
portions of which are encrypted under the domain key; and (b) the cardholder's private 
key. 

Point-of-sale Transaction between a Cardholder and a Merchant on the Computer Network 
A cardholder uses his computer 100 to shop at a merchant's website at merchant's 
computer 120. Referring now to FIG. 3, at step 300, when the cardholder decides what 
goods or services he wants to buy, the merchant presents the cardholder with an electronic 
sales draft. 

At step 310, the cardholder elects to pay the sales draft using the cardholder's 
electronic payment card. At step 320, a representation of the cardholder's electronic 
payment card may be displayed on the cardholder's computer 100. If the cardholder chose 
to protect his electronic payment card with an access code, then at step 330 the cardholder 
unlocks and activates his electronic payment card. If the electronic payment card is 
protected with an access code, then the electronic payment card cannot be activated unless 
the correct access code is entered. The access code can be stored in a variety of locations 
including, without limitation, the cardholder's own memory, or a floppy disk, magnetic 
stripe card, smart card, or disk drive coupled to the cardholder's computer 100. At step 
340, the cardholder's (activated) electronic payment card digitally signs the electronic 
sales draft that was presented to the cardholder in step 300 using the cardholder's private 
key. Optionally, the cardholder's electronic payment card can automatically fill in the 
information used by the sales draft. At step 350, the cardholder's computer 100 sends the 
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digitally signed sales draft and the cardholder's digital certificate to the merchant's 
computer 1 20, where it is received by the merchant's computer 1 20. 

Authorization 

Referring now to FIG. 4, at step 400, the merchant's computer 120 sends, and the 
5 bridge computer 130 receives, an authorization request from the merchant (seller). The 

authorization request includes the electronic sales draft with the cardholder's (buyer's) 
electronic signature and the cardholder's digital certificate. As mentioned above, in one 
embodiment of the invention, the cardholder's digital certificate includes the cardholder's 
verification key (public key) and an encrypted version of the cardholder's PIN for his 

1 0 conventional payment card. 

At step 410, the bridge computer 130 uses the cardholder's verification key to 
confirm (verify) that the cardholder's electronic signature on the sales draft was authorized 
by the cardholder (buyer). If the electronic signature is confirmed, then at step 420 the 
bridge computer 130 extracts the encrypted version of the cardholder's PIN for his 

1 5 conventional payment card from the cardholder's digital certificate and decrypts the PIN 

using the private key associated with the domain key (if the PIN was asymmetrically 
encrypted) or the domain key itself (if the PIN was symmetrically encrypted). In this (or 
in some equivalent) fashion, the bridge computer 130 can verify the binding (of the 
payment particulars and the user's public key) that was performed by the issuer 1 1 0. The 

20 bridge computer 130 uses the decrypted PIN to generate a conventional authorization 

request as is well-known to those skilled in the art of payment card transaction processing 
(see, e.g., Visa International Acquirer Services External Interface Specification, April 1 
1999, EIS 1080 Version 5.8, available from Visa). The decrypted PIN may be re-en- 
crypted with a key that is shared by the bridge computer 130 and the transaction processor 

25 at payment gateway 140. Certain other particulars that are typically used for creating a 

conventional authorization request, such as the conventional payment card number, 
conventional credit card holder verification value 2 ("CVV2"), conventional cardholder 
name and address, or any other cardholder identification information, may also be 
extracted and decrypted from the cardholder's digital certificate. 



WO 01/46918 



10 



PCT/US00/41736 



Note that some types of conventional payment transactions do not necessarily use 
PINs, e.g., some conventional credit card transactions. For these transactions, after the 
bridge computer 130 verifies the cardholder's digital signature on the sales draft at step 
410, the bridge computer 130 generates a conventional authorization request at step 420 
5 without performing the PIN extraction and PIN decryption steps. 

At step 430, the bridge computer 130 sends the conventional authorization request 
to the transaction processor at payment gateway 140. Using the information provided in 
the authorization request, the payment gateway 140 approves or denies the request and 
sends its authorization response back to the bridge computer 130. 
10 In an alternative embodiment of the invention, the bridge computer 130 can be integrated 

into the payment gateway 140. Indeed, any combination of issuer proxy 110, bridge 
computer 130, and/or payment gateway 140 can be integrated together. 

The bridge computer 130 receives from the payment gateway 140 either an 
approval or a disapproval of the authorization request . In either event, at step 440, the 
15 bridge computer 130 forwards the authorization response (approval or disapproval) to the 

merchant (seller) at the merchant's computer 120. 

If the cardholder is making a debit transaction, then at step 450 the merchant's 
computer 120 sends a confirmation to the payment gateway 140 via the bridge computer 
130. 

20 One advantage of this authorization process is that there is minimal impact on the 

merchant. Another advantage is that the payment gateway 140 can interact with the legacy 
back-end systems 1 50 using conventional transaction processing methods. In other words, 
no changes are necessarily required to the back-end infrastructure. 

In an alternate embodiment of the system, the bridge computer 130 can act in 

25 "stand-in" mode. Specifically, some financial institutions may choose not to receive the 

decrypted PIN from the cardholder's digital certificate, relying instead on the bridge 
computer's assertion that the cardholder's signature verified correctly. If the cardholder 
PIN was also verified at the issuer proxy 110 during enrollment, the risk of a fraudulent 
transaction may be deemed low. In such situations, the bridge computer 130 would 

30 assemble and transmit an authorization request without a PFN to the transaction processor 

at payment gateway 140. 
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In yet another embodiment of the system, the merchant can store a copy of the 
digital signature of the cardholder along with the sales draft. The bridge computer 130 
would process the transaction assuming that the digital signature of the cardholder is valid. 
In the event that the cardholder disputes the transaction, the merchant must present the 
5 stored copy of the sales draft and the cardholder's digital signature. The bridge computer 

130 will verify the digital signature and, on the basis of the verification, determine whether 
the merchant should refund the amount of the transaction. An advantage of this embodi- 
ment is that the computational processing required at the bridge computer 130 is reduced. 
However, the merchant faces an increased risk of fraud. 

10 In yet another embodiment of the system, a user who does not have a conventional 

credit or debit card (or who wants to get additional conventional payment cards), can be 
given the option of signing up for a conventional payment card during the electronic 
payment card enrollment process. The conventional payment card number that is given to 
this user can then be incorporated into the user's electronic payment card. 

15 In yet another embodiment of the system, a user may choose to enroll his checking 

account to an electronic payment credential, rather than a debit or credit card. The user 
would identify himself via a variety of means at enrollment time, or may be given an 
activation code by his bank that he would use to identify himself for enrollment. 

Although the preferred embodiments of this invention create an electronic payment 

20 card for conventional debit or credit cards or conventional checking accounts, the present 

invention enables a bridge to network payment for almost any conventional transaction 
system. For example, the present invention could also be used for secure electronic bill 
payment, person-to-person transactions, and electronic auction settlements. 
The software described herein, for use by the various computers, is conveniently imple- 

25 mented using C, C++, Java, Javascript, HTML, or XML, running on Windows, Windows 

NT , Solaris, Unix, Linux, or Macintosh operating systems on virtually any computer 
platform. Moreover, those skilled in the art will readily appreciate that such software can 
be implemented using virtually any programming language, running on virtually any 
operating system on any computer platform. 

30 The various embodiments described above should be considered as merely 

illustrative of the present invention. They are not intended to be exhaustive or to limit the 
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invention to the forms disclosed. Those skilled in the art will readily appreciate that still 
other variations and modifications may be practiced without departing from the general 
spirit of the invention set forth herein. Therefore, it is intended that the present invention 
be defined by the claims that follow. 
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What is claimed is: 

1 . A method for authenticating an electronic payment comprising: 

(a) receiving from a seller an electronic sales draft including an electronic 
signature; 

(b) receiving from said seller a digital certificate associated with a buyer, said 
digital certificate including a verification key and an encrypted version of a 
personal identification number (PIN); 

(c) using said verification key to verify that said electronic signature was 
authorized by said buyer; 

(d) extracting said encrypted version of said PIN from said digital certificate; 

(e) decrypting said encrypted version of said PIN; 

(f) generating, using said PIN, an authorization request; 

(g) sending said authorization request for a PIN to a financial institution; 

(h) receiving an approval of said authorization request from said financial 
institution; and 

(i) sending said approval to said seller. 

2. A method for authorizing an electronic purchase in a networked computer environ- 
ment, comprising the steps of: 

(a) receiving, from a merchant, a transaction authorization request including a 
digital certificate passed through said merchant from a user involved in said 
transaction, 

(i) said digital certificate including a financial account datum associ- 
ated with said user, at least a portion of which is confidential from 
said merchant, 

(ii) said digital certificate conveying a binding between at least a por- 
tion of said financial account datum and a public key of said user; 

(b) verifying said binding using a cryptographic verification key associated 
with a trusted party performing said binding; and 
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(c) using said financial account datum to authorize a transaction order digitally 
signed by said user with a private key corresponding to said public key. 

3. The method of claim 2 where said digital certificate constitutes said binding. 

4. The method of claim 2 where said binding is embedded in said digital certificate. 

5. The method of claim 2 where said financial account datum includes a credit card 
number. 

6. The method of claim 2 where said financial account datum includes a debit card 
number. 

7. The method of claim 2 where said financial account datum includes a PIN. 

8. The method of claim 2 where said financial account datum includes a card verifica- 
tion value 2. 

9. The method of claim 2 where said financial account datum includes checking 
account information. 

10. The method of claim 2 where said binding is performed with a symmetric key 
shared between said trusted party and a party performing said verification step. 

1 1 . The method of claim 2 where said binding is performed with an asymmetric key 
corresponding to said cryptographic verification key. 

12. The method of claim 2 where said binding is performed by an issuer of said digital 
certificate. 
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13. The method of claim 2 a /here said binding is perform by an issuer of said financial 
accounting datum. 

14. The method of claim 2 where said digital certificate is protected with an access 
code known to said user. 

15. A method for providing electronic payment capabilities to a user in a networked 
computer environment, comprising the steps of: 

(a) obtaining a financial account datum associated with said user; 

(b) obtaining a public key associated with said user; 

(c) obtaining a cryptographically assured binding of said public key to at least 
a portion of said financial account datum, 

(i) said binding being conveyed in a digital certificate for said user, 

(ii) said digital certificate being usable by said user to conduct an 
electronic transaction involving said financial account datum; and 

(d) transmitting said digital certificate to said user, enabling said user to 
conduct said electronic transaction involving (i) a merchant from whom at 
least a portion of said financial account datum is kept confidential, and (ii) 
a transaction processor capable of verifying said binding using a crypto- 
graphic verification key associated with a trusted party performing said 
binding. 

16. The method of claim 15 where said digital certificate constitutes said binding. 

1 7. The method of claim 1 5 where said binding is embedded in said digital certificate. 

1 8. The method of claim 1 5 where said financial account datum includes a credit card 
number. 

19. The method of claim 15 where said financial account datum includes a debit card 
number. 
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20. The method of claim 1 5 where said financial account datum includes a PIN. 

21 . The method of claim 1 5 where said financial account datum includes a card 
verification value 2. 

22. The method of claim 1 5 where said financial account datum includes checking 
account information. 

23. The method of claim 1 5 where said binding is performed with a symmetric key 
shared between said trusted party and said transaction processor. 

24. The method of claim 1 5 where said binding is performed with an asymmetric key 
corresponding to said cryptographic verification key. 

25. The method of claim 1 5 where said binding is performed by an issuer of said 
digital certificate. 

26. The method of claim 15 where said binding is performed by an issuer of said 
financial account information. 

27. The method of claim 1 5 further comprising the step, after step (a), of verifying said 
financial account datum. 

28. The method of claim 1 5 where said digital certificate is protected with an access 
code known to said user. 

29. The method of claim 15 where said digital certificate is stored at a credential server 
accessible to said user. 

30. An apparatus for authorizing an electronic purchase in a networked computer 
environment, comprising: 
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(a) a computer processor; 

(b) a memory connected to said processor storing a program to control the 
operation of said processor; 

(c) the processor operable with said program in said memory to: 

(i) receive, from a merchant, a transaction authorization request, said 
request including a digital certificate passed through said merchant 
from a user involved in said transaction, 

(1) said digital certificate including financial account datum 
associated with said user, at least a portion of which datum 
is confidential from said merchant, 

(2) said digital certificate conveying a binding between at least a 
portion of said financial account datum and a public key of 
said user; 

(ii) verify said binding using a cryptographic verification key associated 
with a trusted party performing said binding; and 

(iii) use said financial account datum to authorize a transaction order 
digitally signed by said user with a private key corresponding to 
said public key. 

31. The apparatus of claim 30 where said financial account datum includes a PIN. 

32. The apparatus of claim 30 where said financial account datum includes a card 
verification value 2. 

33. The apparatus of claim 30 where said binding is performed with an asymmetric 
key corresponding to said cryptographic verification key. 



34. 



An apparatus for providing electronic payment capabilities to a user in a networked 
computer environment, comprising: 
(a) a processor; 
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(b) a memory connected to said processor storing a program to control the 
operation of said processor; 

(c) the processor operable with said program in said memory to: 

(i) obtain a financial account datum regarding said user, 

(ii) obtain a public key associated with said user, 

(iii) obtain a cryptographically assured binding of said public key to at 
least a portion of said financial account datum, 

( 1 ) said binding being conveyed in a digital certificate for said 
user, 

(2) said digital certificate being usable by said user to conduct 
an electronic transaction involving said financial account 
datum, and 

(iv) transmit said digital certificate to said user, enabling said user to 
conduct said electronic transaction involving (1) a merchant from 
whom at least a portion of said financial account datum is kept 
confidential, and (2) a transaction processor capable of verifying 
said binding using a cryptographic verification key associated with 
a trusted party performing said binding. 

35. The apparatus of claim 34 where said financial account datum includes a PIN. 

36. The apparatus of claim 34 where said financial account datum includes a card 
verification value 2. 

37. The apparatus of claim 34 where said binding is performed with an asymmetric 
key corresponding to said cryptographic verification key. 

38. A computer-readable storage medium encoded with processing instructions for 
implementing a method for authorizing an electronic purchase in a networked 
computer environment, said processing instructions for directing a computer to 
perform the steps of: 
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(a) receiving, from < . merchant, a transaction authorization request, said request 
including a digital certificate passed through said merchant from a user 
involved in said transaction, 

(i) said digital certificate including a financial account datum associ- 
ated with said user, at least a portion of which datum is confidential 
from said merchant, 

(ii) said digital certificate conveying a binding between at least a por- 
tion of said financial account datum and a public key of said user; 

(b) verifying said binding using a cryptographic verification key associated 
with a trusted party performing said binding; and 

(c) using said financial account datum to authorize a transaction order digitally 
signed by said user with a private key corresponding to said public key. 

39. The computer-readable medium of claim 38 where said financial account datum 
includes a PIN. 

40. The computer-readable medium of claim 38 where said financial account datum 
includes a card verification value 2. 

41 . The computer-readable medium of claim 38 where said binding is performed with 
an asymmetric key corresponding to said cryptographic verification key. 

42. A computer-readable storage medium encoded with processing instructions for 
implementing a method for providing electronic payment capabilities to a user in a 
networked computer environment, said processing instructions for directing a 
computer to perform the steps of: 

(a) obtaining a financial account datum regarding said user; 

(b) obtaining a public key associated with said user; 

(c) obtaining a cryptographically assured binding of said public key to at least 
a portion of said financial account datum, 

(i) said binding being conveyed in a digital certificate for said user, 
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(ii) said digital certificate being usable by said user to conduct an 

electronic transaction involving said financial account datum; and 
(d) transmitting said digital certificate to said user, enabling said user to 

conduct said electronic transaction involving (i) a merchant from whom at 
least a portion of said financial account datum is kept confidential, and (ii) 
a transaction processor capable of verifying said binding using a crypto- 
graphic verification key associated with a trusted party performing the said 
binding. 

The computer-readable medium of claim 42 where said financial account datum 
includes a PIN. 

The computer-readable medium of claim 42 where said financial account datum 
includes a card verification value 2. 

The computer-readable medium of claim 42 where said binding is performed with 
an asymmetric key corresponding to said cryptographic verification key. 

A digital certificate for use in an electronic payment transaction in a networked 
computer environment, comprising: 

(a) a financial account datum associated with a user, at least a portion of which 
datum is confidential from a merchant involved in said payment transac- 
tion; 

(b) a cryptographically assured binding of a public key associated with said 
user to at least a portion of said financial account datum, said binding 
having been generated with a cryptographic verification key associated with 
a trusted party performing said binding; 

(c) said digital certificate configured for use by a transaction processor to: 

(i) verify said binding using a cryptographic verification key associated 
with said trusted party, and 
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(ii) access said financial account datum to authorize a transaction order 
digitally signed with said user's private key corresponding to said 
public key. 

47. The digital certificate of claim 46 where said digital certificate constitutes said 
binding. 

48. The digital certificate of claim 46 where said binding is embedded in said digital 
certificate. 

49. The digital certificate of claim 46 where said financial account datum includes a 
credit card number. 

50. The digital certificate of claim 46 where said financial account datum includes a 
debit card number. 

5 1 . The digital certificate of claim 46 where said financial account datum includes a 
PIN. 

52. The digital certificate of claim 46 where said financial account datum includes a 
card verification value 2. 

53. The digital certificate of claim 46 where said financial account datum includes 
checking account information. 

54. The digital certificate of claim 46 where said binding is performed with a symmet- 
ric key shared between said trusted party and said transaction processor. 

55. The digital certificate of claim 46 where said binding is performed with an asym- 
metric key corresponding to said cryptographic verification key. 
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56. The digital certificate of claim 46 where said binding is performed by an issuer of 
said digital certificate. 

57. The digital certificate of claim 46 where said binding is performed by an issuer of 
said financial account datum. 

58. The digital certificate of claim 46 where said digital certificate is protected with an 
access code known to said user. 
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